La idea de este filtro es crear en cada pixel una impresi\'on de ``desenfoque''. Para esto, necesitamos trabajar con los pixeles aleda\~nos al pixel que estamos procesando.
Como el lector notar\'a, hay ciertos casos en los que no contamos con la cantidad suficiente de p\'ixeles vecinos para procesar la f\'ormula registrada abajo. 

Por una cuestion de claridad, en esta descipci\'{o}n dejaremos de lado los casos borde, que consisten en poner en negro un marco de dos p\'{i}xeles de ancho en la 
imagen destino, y nos enfocamos exclusivamente en una iteraci\'{o}n del ciclo en que se deba hacer operaciones aritm\'{e}ticas para procesar los
p\'{i}xeles de la imagen fuente.

\subsection{Descripci\'on}


Dado un par de \'{i}ndices $(i,j)$ que no representen un caso borde (esto es, donde $i>= 2 \land j>= 2 \land i+2<tamx \land j+2<tamy$), la f\'{o}rmula para el 
p\'{i}xel destino viene dada por: 
\begin{equation*}
dst(i,j) = 0,2*(src(i-2,j-2)+src(i-1,j-1)+src(i,j)+src(i+1,j+1)+src(i+2,j+2))
\end{equation*}

Esta f\'ormula crear\'a el efecto de desenfoque.

La forma en la que procederemos ser\'a la siguiente. Se asume que los casos bordes no presentan conflicto. Esto es para no tener que a\~nadir condiciones al pseudoc\'odigo 
que poco aportan a la comprensi\'on del algoritmo. 

\begin{codesnippet}
\begin{verbatim}
        sea s un puntero al principio de la imagen fuente
        sea d un puntero al principio de la imagen destino
        miestras s permanezca en la imagen
                leer los pixeles necesarios para procesar a partir de s
                sumar para cada pixel a procesar los valores r, g y b de los pixeles necesarios para su procesamiento
                multiplicar las sumas por 0.2
                grabar los pixeles a partir de d
                d = d + 16
                s = s + 16
\end{verbatim}
\end{codesnippet}

Cuando hablamos de ``los pixeles necesarios para procesar'' en el pseudoc\'odigo, no dejamos en claro cu\'ales son. Dado que ser\'ia muy engorroso explicarlo mediante palabras, m\'as
a\'un en un psudocodigo, presentamos un diagrama para explicarlo:

\begin{figure}[H]
    \includegraphics[width=0.6\textwidth]{pixelesMotion}
  \label{mblur14}
\end{figure}

Los p\'ixeles ``a procesar'' son aquellos que, en la f\'ormula, se encuentran en la posici\'on (i,j). Los pixeles ``requeridos'' son aquellos que necesitamos para 
obtener el valor final de acuerdo a la formula.

De manera an\'{a}loga a otros filtros, en una lectura a la imagen fuente leeremos 4 p\'{i}xeles; en este caso, por la f\'{o}rmula que describe el efecto,
ser\'{a} necesario leer 20 p\'{i}xeles, almacen\'{a}ndolos en 5 registros multimedia. 
Luego, para obtener las 5 sumas necesarias para cada uno de los 4 
p\'{i}xeles, hacemos el paso intermedio de desempaquetar para extender la precisi\'{o}n y evitar potenciales overflows, lo cual obliga a tener copias
de los 5 registros para extender la precisi\'{o}n de la parte baja y de la parte alta de cada uno de ellos. De esta manera, tenemos 5 registros
con la informaci\'{o}n para procesar los primeros dos p\'{i}xeles de la imagen destino, y otros 5 con la informaci\'{o}n para el tercero y el cuarto p\'{i}xel.
Luego, procedemos sumando los registros correspondientes. Una vez hecho esto, se tienen dos registros seg\'{u}n muestra la siguiente figura:
\begin{center}
   \begin{tabular}{| l | c | r | c | r | c | r | c | r |c | r |c | r |}
     \hline
     $\Sigma b_0$& $\Sigma g_0$ & $\Sigma r_0$ & $\Sigma a_0$ & $\Sigma b_1$  & $\Sigma g_1$ & $\Sigma r_1$ & $\Sigma a_1$  \\ \hline
   \end{tabular}
\end{center}
  
\begin{center}
   \begin{tabular}{| l | c | r | c | r | c | r | c | r |c | r |c | r |}
   \hline
      $\Sigma b_2$& $\Sigma g_2$ & $\Sigma r_2$ & $\Sigma a_2$ & $\Sigma b_3$  & $\Sigma g_3$ & $\Sigma r_3$ & $\Sigma a_3$  \\ \hline
   \end{tabular}
\end{center}

donde, por ejemplo, la notaci\'{o}n $\Sigma b_{0}$ representa la suma del canal azul de los 5 p\'{i}xeles necesarios para obtener el canal azul del 
p\'{i}xel 0 de la imagen destino.

Teniendo estas sumas, falta multiplicar a cada una por $0.2$. Como dicha operaci\'{o}n debe ser hacerse en aritm\'{e}tica de punto flotante,
es necesario volver a extender la precisi\'{o}n (lo cual conlleva, como antes, guardar copias para operar con las partes alta y baja una vez extendidas)
de word a double word y, en segundo lugar, convertir la representaci\'{o}n de los datos de entera a punto flotante. Una vez hecho eso, se tienen 4 registros
multimedia (cada uno contiene la data correspondiente a un p\'{i}xel para la imagen destino) de la siguiente forma:

\begin{center}
   \begin{tabular}{| l | c | r | c | r | c | r | c | r |c | r |c | r |}
   \hline
      $float(\Sigma b_i$)& $float(\Sigma g_i)$ & $float(\Sigma r_i)$ & $float(\Sigma a_i)$  \\ \hline
   \end{tabular}
\end{center}

donde la notaci\'{o}n $float(x)$ indica el casteo a punto flotante de la suma en aritm\'{e}tica de enteros.

Una vez hecho esto, el siguiente paso es multiplicar a cada suma por la constante $0.2$. Esto se puede hacer f\'{a}cilmente 
definiendo una etiqueta de la forma \verb|constante: dd 0.2, 0.2, 0.2, 0.2|, moviendo lo apuntado por \verb|constante| a un registro multimedia y multiplicando
de forma empaquetada los registros.

Lo que resta es volver a convertir la representaci\'{o}n de los datos de punto flotante a 
entera, luego empaquetar la informaci\'{o}n para que la data ya procesada est\'{e} almacenada en bytes y mover dicha data, ya procesada y en el tama\~{n}o
correcto, a la imagen destino.


\subsection{Experimentaci\'on}

\subsubsection{Secuencial vs. Vectorial}

En este experimento continuamos con la idea de los experimentos 2.2.4, 3.2.1 y 4.2.2 de comprobar la utilidad de programar en un lenguaje de bajo nivel,
como en todos los que llevan el mismo t\'itulo. Nuevamente, los datos
considerados son los que aparecen descriptos en las aclaraciones.  

\begin{figure}[H]
    \includegraphics[width=1\textwidth]{mblur14}
  \label{mblur14}
\end{figure}

Aqu\'i observamos que la versi\'on ASM supera por mucho las optimizaciones. Esto no solo nos lleva a pensar que el modo de procesar los datos que hallamos es el \'optimo para esta 
f\'ormula, sino que adem\'as, apoya la conclusi\'on de que el compilador no logra optimizar de ninguna forma el acceso a datos no consecutivos. Esto indica que cualquier patr\'on 
de acceso de datos que no sea absoluta y completamente trivial de detectar, puede ser mejorado, con respecto a la optimizaci\'on del compilador, programando a bajo nivel.